synology.forum архив спільноти · 2005–2022
ai.synology.forum →
ГлавнаяФайловый Сервер › Прямой доступ к File Station

Прямой доступ к File Station

dik_balbes · 04.02.2015

Добры день.

 

У меня DS 5.1, прямое подключение к интернету (белый IP, без роутера) и настроен адрес mydomen.ru.

Доступ к управлению mydomen.ru:5000 - работает.

Подключени к File Station mydomen.ru:7000 порту - работают.

Я так понимаю, что если запустить Web Station, то можно сделать несколько сайтов и заходить на них по адресам,

например site1.mydomen.ru, site2.mydomen.ru и т.д. (т.е. без прописывания портов в адресной строке, а только по имени попадать на сайт).

 

А как сделать так, что бы по file.mydomen.ru попадать на File Station ?

 

Я так понимаю, что можно настроить VirtualHost в файле httpd.conf, вот только куда перенаправлять я так и не понял.

ValeryFVV2002 · 04.02.2015

301 редирект, например, в .htaccess с file.mydomen.ru на mydomen.ru:5000 не устроит?

 

Кстати, вэб сервер не фонтан. Так что...

Siroc-co · 04.02.2015
Я так понимаю, что можно настроить VirtualHost в файле httpd.conf, вот только куда перенаправлять я так и не понял.

Перенаправление, насколько знаю, можно сделать только для приложений, которые находятся в папке web. А попасть на FileStation можно так mydomen.ru:7000/file/ , если заданы соответствующие настройки в портале приложений. Ну или сделать А запись вида file.mydomen.ru = xxx.xxx.xxx.xxx:7000/file/ если позволят, в чём я сомневаюсь.

Если пользоваться этим сервисом, https://www.cloudns.net , то можно сделать перенаправление.

polanat · 04.02.2015
А попасть на FileStation можно так mydomen.ru:7000/file/ , если заданы соответствующие настройки в портале приложений.

Для такого доступа придётся дополнительно делать на роутере проброску 7000 порта. Проще использовать уже открытый порт mydomen.ru:5000/file

 

PS Security Advisor таки будет ругаться на стандартный порт 5000 :(

ValeryFVV2002 · 04.02.2015

Не знаю, в чем сложности

Все работает с редиректом нормально

Ззаводите в корне сайта file.mydomen.ru файл .htaccess

и пишите строки

 

RewriteEngine On

RewriteRule ^(.*)$ http://mydomen.ru:5000/$1 [R=301,L]

 

При чем тут приложения - непонятно, так как с одного домена идет перенаправление на другой

Или я не понимаю проблему, или вы чего-то мудрите...

Mikle · 04.02.2015
Не знаю, в чем сложности

Все работает с редиректом нормально

Ззаводите в корне сайта file.mydomen.ru файл .htaccess

и пишите строки

 

RewriteEngine On

RewriteRule ^(.*)$ http://mydomen.ru:5000/$1 [R=301,L]

 

При чем тут приложения - непонятно, так как с одного домена идет перенаправление на другой

Или я не понимаю проблему, или вы чего-то мудрите...

 

Скажите, а у Вас что в итоге будет в строке браузера? Мне кажется, она быстренько заменится с file.mydomen.ru на http://mydomen.ru:5000/... Работать то естественно будет, но физический запрос все равно а) будет требовать открытого и проброшенного 5000 порта, б) мозолить глазки юзера некрасивым url с портом

 

Как я понял человека, нужно, чтобы в адресной строке браузера остался неизменным file.mydomen.ru

Возможно и я не верно понял, но если уж делать красиво, то как-то надо в этом направлении двигаться

dik_balbes · 04.02.2015
301 редирект, например, в .htaccess с file.mydomen.ru на mydomen.ru:5000 не устроит?

Спасибо, все работает

 

Не знаю, в чем сложности

Все работает с редиректом нормально

Ззаводите в корне сайта file.mydomen.ru файл .htaccess

и пишите строки

 

RewriteEngine On

RewriteRule ^(.*)$ http://mydomen.ru:5000/$1 [R=301,L]

Можешь подсказать чем твой вариант отличается от

Redirect 301 / http://mydomen.ru:5000/

 

Просто ни когда не работал с .htaccess

 

Как я понял человека, нужно, чтобы в адресной строке браузера остался неизменным file.mydomen.ru

Возможно и я не верно понял, но если уж делать красиво, то как-то надо в этом направлении двигаться

Конечно вариант, когда порт совсем не фигурирует в адресной строке, самый идеальный

Но я так понимаю, что его своими силами тяжело добиться и придется ждать, когда Synology это сделают

А пока буду наслаждаться предложенным вариантом

Тимур Рахимов · 04.02.2015

Ну, не так уж тяжело. Ключевые слова — «virtual server», «reverse proxy» плюс ручное редактирование конфигурационного файла httpd.conf. У меня работает такое уже давно. Если кому-нибудь не жалко на это усилий, могу рассказать.

dik_balbes · 04.02.2015
Ну, не так уж тяжело. Ключевые слова — «virtual server», «reverse proxy» плюс ручное редактирование конфигурационного файла httpd.conf. У меня работает такое уже давно. Если кому-нибудь не жалко на это усилий, могу рассказать.

Сделай подробную инструкцию, если не сложно

Т.к. это очень полезная информация, которую очень сложно найти

Mikle · 04.02.2015
Ну, не так уж тяжело. Ключевые слова — «virtual server», «reverse proxy» плюс ручное редактирование конфигурационного файла httpd.conf. У меня работает такое уже давно. Если кому-нибудь не жалко на это усилий, могу рассказать.

Сделай подробную инструкцию, если не сложно

Т.к. это очень полезная информация, которую очень сложно найти

Присоединяюсь. Я сделал нечто подобное, установив на роутере NGINX. Использую такие конструкции:

# Секция для перенаправления http на https
# Строка браузера меняется
server {
listen 80;
server_name mydomen.ru;

location / {
  rewrite ^(.*)$ https://$server_name$1 permanent;
}
}

# Секция для внутреннего редиректа
# Строка браузера НЕ меняется
server {
listen 443;
server_name mydomen.ru;

ssl on;
ssl_certificate /opt/etc/nginx/ssl/server.crt;
ssl_certificate_key /opt/etc/nginx/ssl/server.key;

location /photo {
  proxy_pass https://mydomen.ru;
}

location / {
  proxy_pass https://mydomen.ru:5001;
}
}

Ну и так далее, все не буду выкладывать. Смысл в том, что идем не на домен 3-го уровня, а на свой домен 2-го уровня + слэш папка (http://mydomen.ru/file - который так и останется в строке браузера, но физически запрос будет перенаправлен на строчку из proxy_pass)

 

Кое-что работает, но есть небольшие дефекты.

Тимур, можете описать свой вариант? Понимание линукса, работы в консоли, редактора vi имеется. Времени не жалко. Опишите, пожалуйста

ValeryFVV2002 · 04.02.2015
Можешь подсказать чем твой вариант отличается от

Redirect 301 / http://mydomen.ru:5000/

 

Просто ни когда не работал с .htaccess

 

По сути - ничем. Только записью ;)

 

Тимур Рахимов · 04.02.2015

Хорошо, давайте начнём. Сначала — о скучном, но необходимом для понимания. Используются две ключевые особенности веб-сервера, на котором работает Synology — Apache: виртуальные хосты (virtual hosts) и прокси на стороне сервера (reverse proxy), обе они встроены в веб-сервер, так что ничего больше, кроме редактирования конфигурационных файлов и перезапуска процессов, не потребуется. Правда, чтобы научиться это делать тем, кто ранее с Unix-подобными системами дела не имел, нужно будет преодолеть какой-то минимальный входной порог, но дело, мне кажется, стоит того. Исходные условия: у нас версия DSM 5.0 или более поздняя, мы умеем подключаться с помощью программы типа «Терминал» по протоколу SSH или Telnet к нашей Synology (доступ по одному из этих протоколов нужно на ней предварительно разрешить и — важная деталь — входить не с именем admin, а с именем root, пароль тот же), умеем пользоваться встроенным редактором файлов vi, работающим прямо из командной строки (или, если это кажется неудобным, воспользоваться какой-нибудь альтернативой для доступа к файлам, находящимся за пределами пользовательского раздела; среди таких я знаю программу WinSCP для Windows и Config File Editor — сторонний модуль непосредственно для DSM), обладаем минимальными знаниями для того, чтобы ориентироваться в интерфейсе командной строки (ну там сменить текущий каталог, посмотреть содержимое каталога, запустить команду, просмотреть текстовый файл и т. п.).

 

Веб-сервер Apache работает на Synology в трёх экземплярах: системный (этот процесс обслуживает веб-интерфейс DSM), пользовательский (это сайты пользователей и Photo Station, а также некоторые другие пакеты) и отдельный экземпляр для WebDAV. Последние два будут существовать, если включены соответствующие настройки в веб-интерфейсе DSM. Нас интересует «пользовательский» экземпляр, его конфигурация находится в файле /etc/httpd/conf/httpd.conf-user

 

Наши добавления в конфигурацию очевидным образом нужно будет внести в конец файла, но тут нас стерегут неожиданности. Следует иметь в виду, что при переконфигурировании веб-сервера (а это случается всякий раз, когда вы ставите и удаляете галочки в веб-интерфейсе DSM, затрагивающие веб-сервер — в основном они находятся в разделе «Веб-службы»), сама Synology может что-то дописать в конец, испортив, а то и уничтожив вашу конфигурацию. То же самое (и даже хуже — полное перезатирание конфигурации), кстати, случается при обновлении операционной системы, поэтому в любом случае после такого обновления нужно будет восстанавливать то, что мы себе так любовно настроили, поэтому нужно уже с самого начала распланировать всё так, чтобы это давалось наименьшей кровью. Не могу вам навязывать, но я решил для себя эту задачу так: вместо того, чтобы редактировать «штатный» файл конфигурации с риском, что с очередным обновлением или переконфигурацией там что-то важное изменится, всё мне испортив, я на его основе сделал свой собственный конфигурационный файл, и пользуюсь им не в дополнение к предусмотренному программистами Synology, а вместо него. Находится мой файл на пользовательском разделе: /volume1/web/httpd.conf, а чтобы Apache при запуске игнорировал штатный, и подключал мой файл, пришлось добавить всего одну строчку ещё в один конфигурационный файл: /etc/init/httpd-user.conf

 

Несмотря на похожее имя, это не есть конфигурационный файл Apache, это скрипт его запуска (аналогичные скрипты в том же каталоге есть и для множества других сервисов). Там, в районе 90-й строки нужно произвести изменения (вставить строчку) так.

 

Было:

 

script
    . /run/httpd/http-user-upstart
    exec env TMPDIR=${TmpDir} PATH=${PHP_PATH} /usr/bin/httpd $startArg
end script

 

Стало:

 

script
    . /run/httpd/http-user-upstart
    startArg="$startArg -f /volume1/web/httpd.conf"
    exec env TMPDIR=${TmpDir} PATH=${PHP_PATH} /usr/bin/httpd $startArg
end script

 

Собственно говоря, при таком подходе это будет единственным изменением, которое нужно будет восстанавливать даже после полного обновления системы. Смысл изменения прост: добавить в командную строку запуска опцию, говорящую серверу Apache (его «пользовательскому» экземпляру) при старте: возьми конфигурацию из указанного файла, проигнорировав ту, путь к которой зашит у тебя в коде при компиляции.

 

Поздно уже, спать пойду, потом продолжу, извините.

Siroc-co · 05.02.2015
Или я не понимаю проблему, или вы чего-то мудрите...

Да. Не понимаете. Редирект - не красиво. Это всего лишь пинок с одного адреса на другой, и в результате этого пинка ты окажешься в итоге не на file.mydomen.ru, а на mydomen.ru:XXXX/file, что не красиво. Вопрос в том, как сделать красиво и оставаться там, куда пришёл без "пинков", вот если бы это было приложение в папке WEB, то так сделать было бы можно.

Mikle · 05.02.2015

Тимур, великолепное начало. Вы умеете объяснять достаточно хорошо и понятно. С нетерпением ждем продолжения. Крохотное замечание. Далее, как я понимаю, речь пойдет только о пользовательском экземпляре. Не пытались ли Вы победить так же и интерфейс DSM ? Его рабочий стол так же нужно открывать не по 5000/5001, а по 80/443, а именно без порта. Но даже если Вы не думали на эту тему, все равно ждем продолжения, т.к. Ваша информация неоценимо полезная

Тимур Рахимов · 05.02.2015
Не пытались ли Вы победить так же и интерфейс DSM ? Его рабочий стол так же нужно открывать не по 5000/5001, а по 80/443, а именно без порта.

Спасибо вам за доброе слово. Ну конечно же, эта задача и решалась в первую очередь! В том-то и суть решения, что «пользовательский» экземпляр (отвечающий как раз по портам 80 и 443), поддерживая сеанс с обратившимся к нему пользователем, за сценой незаметно для него транслирует обращения на любой другой сервер и порт, и возвращает пользователю его ответы. Целевым сервером при этом может быть и веб-интерфейс Synology, работающий по порту 5000, и вообще любой сервер на любом порту в интернете (этому серверу необязательно даже быть на Synology). Вот эта технология и называется как раз reverse proxy.

Mikle · 05.02.2015

С еще большим нетерпением ждем продолжения!

andriyashev · 05.02.2015

Со стороннего домена у меня получалось. Создал домен там отредактировал(создал) зону SRV и A, указал сервер, порт итд итп. А с самого Synology тоже интересно возможно ли сделать.

ValeryFVV2002 · 05.02.2015
Да. Не понимаете. Редирект - не красиво. Это всего лишь пинок с одного адреса на другой, и в результате этого пинка ты окажешься в итоге не на file.mydomen.ru, а на mydomen.ru:XXXX/file, что не красиво. Вопрос в том, как сделать красиво и оставаться там, куда пришёл без "пинков", вот если бы это было приложение в папке WEB, то так сделать было бы можно.

 

Вопрос был "как попасть". Про "красиво" - в вопросе ни слова. ;)

Тимур Рахимов · 05.02.2015

Продолжим. Для того, чтобы управлять посредством веб-интерфейса различными устройствами по одному IP-адресу (но указывая различные доменные имена), нам потребуется такая возможность веб-сервера, как виртуальные хосты. Технически говоря, виртуальный хост — это фрагмент (блок) конфигурационного файла, ограниченный открывающим и закрывающим тегами: <VirtualHost (спецификация адреса)> ... </VirtualHost>, внутри которого можно независимо от других таких же виртуальных хостов указывать различные директивы, влияющие на отображение сайта (в первую очередь, откуда брать данные для его отображения). В одном-единственном конфигурационном файле таких блоков может быть сколько угодно. Ещё проще сказать — виртуальные хосты — это средство разместить несколько различных сайтов на одной машине, обслуживаемых одним экземпляром веб-сервера, и даже на одном IP-адресе, как в нашем случае.

 

Как же в этом последнем случае веб-сервер разберётся, в конфигурацию какого виртуального хоста смотреть, чтобы ответить на пришедший запрос? Очень просто — по имени виртуального хоста, который назначается каждому такому блоку <VirtualHost ...> ... </VirtualHost> специальной директивой вида ServerName https://diskstation.ххх.synology.me. Если имя, присвоенное таким образом виртуальному хосту, в точности совпадает со строкой, набранной пользователем в браузере в качестве адреса сайта (его сервер «видит» в поле Host: HTTP-запроса), то для обработки запроса веб-сервер использует соответствующий блок директив из конфигурации.

 

Каждый пользователь Synology, если он в принципе имеет возможность доступа извне, уже располагает DDNS-адресом вида xxx.synology.me (где xxx — это выбранное вами имя), который автоматически сопоставляется текущему IP-адресу устройства. Что для нас здесь особенно важно, на этот единственный IP-адрес будут переадресовываться также домены 3-го уровня, соответствующих вашему (любые, спасибо за этот подарок Synology), например: diskstation1.xxx.synology.me, diskstation2.xxx.synology.me, photostation.xxx.synology.me, router.xxx.synology.me и т. п. Осталось только научить ваш сервер различать запросы, приходящие на эти определённые вами адреса, и обрабатывать их по-разному (для этого и служат виртуальные хосты).

 

Как именно обрабатывать? С помощью технологии reverse proxy, как я уже упомянул раньше. Можно было бы, конечно, в виртуальных хостах поставить простую переадресацию, но, как уже справедливо здесь отмечали, этот подход имеет недостатки. Лучше будет скрывать от пользователя, на какой в действительности адрес нужно перенаправить запрос, то есть за кулисами транслировать запросы пользователя ему, и возвращать аналогичным образом ответы. Это не совсем тривиальная задача (задумайтесь, например, о том, что в возвращаемых страницах везде нужно подправлять ссылки, чтобы они указывали на адреса виртуального хоста, а не на истинные), но, к счастью, всё это за нас уже сделали. Всю работу выполняют лишь две директивы, примерно так (упрощённая конфигурация):

 

<VirtualHost *:443>

    ServerName https://diskstation1.xxx.synology.me


    # единственная необходимая для работы https (SSL) внутри виртуального хоста директива (остальное берётся из общей конфигурации)
    SSLEngine on
    
    # у нас только "обратный", серверный прокси, "прямой" прокси (обслуживание запросов клиентов) со стороны отключаем в целях безопасности
    ProxyRequests Off

    # это нужно было бы включить, если бы мы перенаправляли на https (а поскольку в локальной сети шифрование не требуется, в этом нет смысла)
    #SSLProxyEngine on

    ProxyPass / http://192.168.1.21:5000/
    ProxyPassReverse / http://192.168.1.21:5000/

</VirtualHost>

 

Специально показал в качестве примера виртуальный сайт HTTPS, как чуть более сложную конфигурацию (реальные фрагменты конфигурационного файла — для «жизни» там ещё кое-что надо предусмотреть — покажу позже).

Mikle · 05.02.2015

Правильно ли я понимаю, что раз мы не шифруем локальный трафик, значит перенаправление на 5001 (https) нужно отключить в настройках DSM ? Но если это так, а как видно из примера, что из вне мы все-таки идем к 443 порту (https), значит нам нужно где-то в конфиге прописать наш путь к ssl сертификату. Где это делается?

И еще скромный вопрос. Как не перезагружая весь syno, перезагрузить веб-сервер для того чтобы конфигурация новая подхватилась?

Тимур Рахимов · 05.02.2015

Да, вы понимаете правильно. Галочку «Перенаправлять соединения http на https», если вы также оставляете доступ к DSM по https (порт 5001 по умолчанию), нужно будет отключить. Но надо заметить, что галочку «Включить соединения https» на вкладке Сеть/Настройки DSM можно вообще отключить (тогда и галочка «Перенаправлять соединения http на https» станет недоступной), всё равно все подключения к DSM будут только по http и только по порту 5000, даже когда мы обращаемся извне и по https. Но если вы также захотите обращаться по https (чтобы не светить пароль открытым текстом) к отдельным службам с помощью мобильных приложений вроде Download Station, Audio Station и т. п. по другим, предустановленным для них портам (8001, 8801, ...), эту галочку придётся оставить.

 

Если мы в настройках виртуального хоста не указываем ни путей к сертификатам, ни методы шифрования, ничего, кроме SSLEngine on, то недостающие настройки берутся из общей части конфигурационного файла веб-сервера (в текущей версии у Synology сейчас это довольно запутанно, целая куча конфигурационных файлов для SSL, вложенных друг в друга с помощью Include, конкретно пути к сертификатам и методы шифрования содержатся в файле /etc/httpd/conf/extra/httpd-ssl.conf-cipher). Но можно, разумеется, если вам нужно для разных виртуальных хостов иметь разные сертификаты и др., включить нужные настройки внутрь блока директив соответствующего виртуального хоста.

 

Чтобы перезапустить только пользовательский экземпляр Apache на Synology, нужно в консоли дать команду synoservicectl --restart httpd-user.

Smoke74 · 06.02.2015
но я решил для себя эту задачу так: вместо того, чтобы редактировать «штатный» файл конфигурации с риском, что с очередным обновлением или переконфигурацией там что-то важное изменится, всё мне испортив, я на его основе сделал свой собственный конфигурационный файл, и пользуюсь им не в дополнение к предусмотренному программистами Synology, а вместо него.

Я пошел другим путем: написал скрипт сравнивающий конфигурационные файлы при старте системы, в случае различий - подмена и перезапуск служб. Но палка о двух концах, неожиданность случилась с переходом на DSM 5.0

frodoman · 13.08.2016

Виртуальный файловый сервер

 

Вопрос хранения данных, в том числе и корпоративных, это одна из задач, которую решают виртуальные серверы.

 

С выделенными реальными серверами все сложно:

 

* Их аренда достаточно дорогое удовольствие;

 

* В случаях возникновения необходимости масштабирования, процесс увеличения возможностей аппаратного обеспечения сложный и дорогой;

 

* Необходимо настраивать и обслуживать сервер самостоятельно.

 

Виртуальный файловый сервер – это мощное и эффективное решение, которое позволяет разработчику существенно упростить работу с программной и аппаратной средой, а владельцу проекта снизить свои расходы. Полная статья тут